The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
Today, maps of geographic regions may be displayed by software applications running on a wide variety of devices, including desktop computer devices, mobile phones, car navigation systems, hand-held global positioning system (GPS) units, tablet or laptop computers, etc. Depending on the application and/or user preferences, maps may display topographical data, street data, urban transit information, traffic data, etc. Further, some applications display maps in an interactive mode, so that a user may operate various controls (radio buttons, scrollbars, etc.) to change the zoom level or pan the map to a new location, for example. A user in some cases also may select or unselect the display of certain information. For example, the user may operate the appropriate control to turn on the display of bicycle trails, transmit maps, etc.
To render a map image, a display device typically receives raster image data from a dedicated server. For example, a map server may operate on the Internet and provide images in a Portable Network Graphics (PNG) format to various client devices for the specified geographic regions. While raster images are relatively easy to render at a client device, raster image data typically requires a large amount of storage space for a comprehensive map. Also, it is difficult to efficiently manipulate raster images at a client device. For example, to zoom in on a selected region, either new raster image data is retrieved from the server, or the available raster image data is enlarged with a noticeable loss in quality. To alleviate this issue, some mapping systems provide mapping data from the map server to the client device in the form of vector graphics data. Generally speaking, vector graphics data describes or specifies various features to be included in a map, and a graphics engine on the client device processes the vector graphics data to produce a map image using various common techniques.
In any event, most web based mapping services send map data from a server to a client as small image tiles, typically in the form of raster image data tiles or vector image data tiles. Each image tile covers a predetermined geographic region and specifies the exact image to be displayed, either using raster or vector graphics image data. Moreover, many client-server mapping applications provide a user with many different views of the same basic map data. These views may, for example, provide driving-focused maps, bicycling maps, terrain maps, transit maps, business-focused maps, etc. When the user wants to switch to another map view (e.g., a transit map view) of a particular geographic location, the client application requests a whole new set of map tiles for the same location, but specifying the styling and data differences to be included in the new map view (e.g., including transit lines, with reduced emphasis on roads, etc.). Typically however, all or most of the available map views share most of the same data. For example, the land formations, the lakes, the roads, etc., stay the same between all views, but each view may include a few additional features, may have a few features removed and/or may have a few features that are displayed in different manners or styles. In fact, in most cases, the majority of the map data (in terms of bytes of storage) in these different views is common. Thus, if a mapping application allows the user to switch between different map views for the same geographic region, most of the data sent from server to client is actually redundant with data the client device already has received. This fact can cause a number of problems, including high loading latency, high rendering latency on the client device, high serialization latency on the server, and forced reduction of data detail to avoid these problems.
Moreover, when new map data is sent to a client device, the client device must process the new map data to render the map associated with the new map data. When the new map data is much the same or overlaps with a previously rendered set of map data, the graphics processing unit must typically spend as much processing power on the new map data as the original map data, even though much of the final map is the rendered in the same manner. In particular, in graphics processing unit (GPU) based graphics systems, data must be buffered from the CPU RAM to GPU VRAM before the data can be rendered as a map. Often, before providing data to the GPU, the software must also perform some degree of preprocessing on the data (also called preparing the data), which in some cases can be very computationally expensive and which adds to the total computational cost of rendering that data. Once the data preparation is performed and the data has been sent to the GPU, the data can be redrawn many times without paying the performance cost of preparation and buffering. However, changes to the data in the form of new map data typically requires the same level of preprocessing and preparing and thus does not enable the re-use of previously processed map data that is basically the same in the newly rendered map.
There are many types of graphics systems that have the need to render some data, modify the data somewhat, and re-render it as a new image. Most of these systems have sufficient performance capability (GPU and CPU processor capability) to take the brute force approach, which is to simply modify the data, preprocess or prepare the data as if it was a totally new image and re-buffer the preprocessed image for rendering in the GPU. However, some systems, such as mapping system, tend to be performance intensive and cannot afford all of the duplicated processing work to perform well at the speed at which new map images need to be rendered. These systems require a methodology that avoids re-preparing and re-buffering data prior to rendering that data with the graphics processing unit.